The response timeout problem has been treated as follows in a number of standards or draft standards:
(a) Situation in a Wired IEEE1394-1995 Bus Environment:
A split transaction is characterized by a request subaction and a subsequent responder subaction using the same transaction label (i.e. an identifier of the transaction).
A value in the SPLIT_TIMEOUT control and status register specifies a maximum time period for a particular IEEE1394 node, in which the response to a request has to be generated and sent. If the specified time period (or twice the time period as specified in the IEEE1394a standard respectively) has elapsed without a response being transmitted, the complete transaction fails and the transaction label can be reused (“recycled”) by the requesting node.
Reference: IEEE Standard for a High Performance Serial Bus (IEEE 1394-1995), IEEE New York, 1996
IEEE Standard for a High Performance Serial Bus—Amendment 1 (IEEE1394A-2000), IEEE New York, 2000
(b) Situation in the BRAN Hiperlan 21394 SSCS
The BRAN Hiperlan 2 IEEE1394 Service Specific Convergence technical specification describes how a Hiperlan 2 (HL2) link can be modeled as a virtual IEEE 1394 bus. Therefore, a HL2 split timeout is defined in a fashion similar to an IEEE Std 1394-1995 split timeout, but with a 200 ms default value instead of 100 ms.
An algorithm at the sending portal defines, with help of this SPLIT_TIMEOUT value, a time_of_life period for each particular asynchronous request or response intended to be transmitted over the HL2 wireless link. The time_of_life parameter will be converted to a time_of_death label attached to each asynchronous packet. This time_of_death label advises the receiver of this packet on the wireless link to discard it, if its intended end of life has been reached. The format of the SPLIT_TIMEOUT register defined by the SSCS document differs slightly from the specifications IEEE 1394-1995 and IEEE 1394a-2000.
Reference: IEEE 1394 Service Specific Convergence Sublayer (DTS/BRAN-00240004-3 V1.1.1), ETSI Project Broadband Radio Access Networks (BRAN), Sophia Antipolis, September 2000
(c) Proposed Situation in the IEEE P1394.1 Bridge Environment
Due to longer transmission delays in a bridge environment, this easy split_timeout mechanism cannot be used anymore if split transactions are intended to pass bridges between busses. Instead of the ‘split_timeout’ parameter, a ‘remote_timeout’ parameter is defined.
The ‘remote_timeout’ parameter in an IEEE P1394.1 bridge environment can be determined by sending a message called a TIMEOUT bridge management message with a particular ‘timeout’ opcode to a virtual node identifier. The virtual node identifier represents the destination node which, since it is not on the same bus as the requesting node, does not have a physical identifier on the bus of the requesting node. In the response to this packet, the requesting node will receive the accumulated maximum delay times of all intermediate bridges.
The draft IEEE P1394.1 distinguishes different delay times in a bridge for requests (MAX_RQ_FORWARD_TIME) and responses (MAX_RESP_FORWARD_TIME). These times are implementation dependent and have to be provided by the manufacturer of the bridge.
A description of the ‘TIMEOUT bridge management message’ is given in section 6.7 of P1394.1 Draft D 0.11. Section 4.2 also describes the overall process.
Reference: IEEE Draft Standard for High Performance Serial Bus Bridges (IEEE P1394.1 Vers. 0.11) IEEE 1391.1 working group (standard not yet approved)